Typed stack allocation

The verification of memory safety–no program will crash when referencing memory–falls into two categories. A runtime system may enforce memory safety at a cost. Or, we may rely on error-prone programmers. Runtime overhead, most noticeably garbage collection, is undesirable in embedded or real-time systems. The frequency of collection points is not deterministic. Languages that rely on garbage collection suffer from poor cache locality, occupy more memory than necessary, and usually spend more time copying data throughout memory hierarchy than performing meaningful computations. With enough memory, Appel [2] claims that it is more expensive to explicitly free memory than to leave it for a garbage collector. While garbage collection yields simpler and cleaner syntax, it is worth understanding the circumstances under which garbage collection can be ‘cheaper’ than manually deallocating memory. The result of Appel’s work states that garbage collection becomes less expensive when you have seven times as much memory as you have data within your program. Relying on programmers to safely and explicitly allocate, access, and deallocate memory has been the infamous source of unreliable software. There are many advantages to explicit memory management e.g. deallocating memory immediately after it’s last access instead of waiting for a GC to reclaim it. However, this ad-hoc method of verification has proven over time that secure software systems require a machine to verify memory safety. Why is it that the most popular techniques for guaranteeing memory safety impose runtime overhead?